Process control systems, like those used in chemical, petroleum or other processes, typically include one or more centralized process controllers communicatively coupled to at least one host or operator workstation and to one or more field devices via analog, digital or combined analog/digital buses. The field devices, which may be, for example valves, valve positioners, switches and transmitters (e.g., temperature, pressure and flow rate sensors), perform functions within the process such as opening or closing valves and measuring process parameters. The process controller receives signals indicative of process measurements made by the field devices and/or other information pertaining to the field devices, uses this information to implement a control routine and then generates control signals that are sent over the buses or other communication lines to the field devices to control the operation of the process. Information from the field devices and the controllers may be made available to one or more applications executed by the operator workstation to enable an operator to perform desired functions with respect to the process, such as viewing the current state of the process, modifying the operation of the process, etc.
Typically, a process control system operates within a business enterprise that may include several process control plants, component and/or service suppliers and customers, all of which may be distributed throughout a large geographic area or, in some cases, throughout the world. The process control plants, suppliers and customers may communicate with each other using a variety of communication media and technologies or platforms such as, for example, the Internet, satellite links, ground-based wireless transmissions, telephone lines, etc. Of course, the Internet has become a preferred communication platform for many business enterprises because it provides an established communications infrastructure, thereby minimizing or reducing the communication infrastructure costs for an enterprise. Additionally, the technologies used to communicate information via the Internet are well-understood, stable, secure, etc.
Each process control plant within an enterprise may include one or more process control systems as well as a number of other business-related or information technology systems that are needed to support or maintain, or that are complementary to, the overall operation of the process control systems. In general, the information technology systems associated with a process control plant may include manufacturing execution systems such as, for example, a maintenance management system and may also include enterprise resource planning systems such as, for example, scheduling, accounting and procurement systems. Although these information technology systems may be physically located within or near a plant, in some cases a few, or possibly all, of these systems may be remotely located with respect to the plant and may communicate with the plant using the Internet or any other suitable communication link using any desired combination of wireless and/or hardwired communication media and techniques.
Each process control plant within an enterprise may also include user-interactive applications that may be executed on a server or workstation that is communicatively coupled to one or more servers, workstations, or other computers that coordinate or perform the activities of the process control system within the plant. Such user-interactive applications may perform campaign management functions, historical data management functions, asset management functions, batch management functions, etc. In addition, each of the process control systems may include process management applications that may, for example, manage the communications of and provide information relating to alarm and/or other process events, provide information or data relating to the condition of the process or processes performed by the process control plant, provide information or data relating to the condition or performance of equipment associated with the process control plant, etc. In particular, process management applications may include vibration monitoring applications, real-time optimization applications, expert system applications, predictive maintenance applications, control loop monitoring applications, or any other applications related to controlling, monitoring and/or maintaining a process control system or plant.
Still further, a process control plant or enterprise may include one or more communication applications that may be used to communicate information from the process control system or plant to a user via a variety of different communication media and platforms. For example, these communication applications may include e-mail applications, paging applications, voice messaging applications, file-based applications, etc., all of which may send information via wireless or hardwired media to a desktop computer, a laptop computer, a personal data assistant, a cellular phone or pager, or any other type of device or hardware platform.
Generally speaking, enabling communications between and integrating information technology systems, user-interactive applications, process management applications and communication applications within an enterprise is extremely difficult because these systems and applications are typically distributed widely throughout the enterprise and, in some cases, are widely geographically dispersed. Further, many of the aforementioned systems and applications may be executed via handheld or portable hardware platforms such as, for example, laptop computers, cellular phones, pagers, personal data assistants, etc., many of which are configured to provide an operating environment suitable for executing complicated client applications or software including, for example, web browsers or the like that perform communication functions.
Additionally, these systems and applications typically require the development of a custom communication interface or software driver that enables the different systems and applications to communicate with each other. As a result, when any system, application, device or component within the enterprise changes due to, for example, a firmware upgrade, device replacement, etc., the custom communication driver or interface for that system, device or component may also have to be changed. Obviously, the large number of custom drivers needed results in a lot of time-consuming driver maintenance, which results in high enterprise maintenance costs. Furthermore, adding a system or application to an enterprise or a process control plant often requires an enormous programming effort because a plurality of custom communication drivers or interfaces may have to be developed to enable the new system or application to communicate with the other systems and applications within the enterprise. Thus, systems that use such custom communication interfaces are not very flexible or scalable and do not facilitate, for example, the integration of a process control system with other systems and applications, which may be provided by the manufacturer of the process control system and/or by a third party manufacturer or developer.
More recent developments directed at improving the flexibility and scalability of systems within enterprises have been accompanied by the development and proliferation of improved operating systems such as, for example, Windows XP®, Microsoft .NE™, etc. and communication protocol improvements such as, for example, Ethernet, voice over Internet protocol (IP), streaming video, etc. In addition, improved information or data transfer and central data storage devices and techniques such as those provided by, for example, extensible markup language (XML), simple object access protocol (SOAP), universal description, discovery and integration (UDDI), etc., improved orchestration systems or servers such as, for example, Biztalk®, improved programming languages that are execution platform insensitive such as, for example, Java, and a host of other improved communication and/or data management tools, standards, protocols, programming languages, etc. have been developed.
While many recent developments have increased the ease with which a plurality of systems composing a business enterprise can be configured to communicate with each other, the overall system architecture within which these systems interoperate has not meaningfully changed from well-known client-server architectures. With many known client-server architectures, clients send collected data or information to a server and receive processed results from the server that may be displayed and/or otherwise utilized by a system operator. Additionally, the server typically retains and implements or executes business or database rules to operate on or process data received from one or more clients.
Unfortunately, the use of known client-server architectures within an enterprise, process control plant, or process control system having a plurality of distributed systems that communicate via one or more communication networks is relatively inefficient because the server typically retains and executes the business logic, database rules, and/or other data intensive processing. As a result, clients must typically engage in a large number of round trip communications with the server (i.e., send requests to the server for information or data and execution of business logic and receive responsive communications from the server). A large number of round trip communications within a distributed system based on known client-server architectures can consume a significant amount of limited and, thus, valuable communication network or channel bandwidth. For example, in the case of wireless communication links (e.g., cellular and satellite links) channel bandwidth is relatively expensive and, thus, the cost per packet, bit, etc., is relatively high. In addition, communication channel latency (i.e., round trip transmission time) can result in substantial time delays, which may be unacceptable for many process-oriented functions, particularly real-time process control functions.
In any event, communication inefficiencies or difficulties due to bandwidth restrictions, costs, communication channel latency, etc. are aggravated in situations where clients are engaged in process-oriented functions and/or where servers implement process-oriented business logic because these process-oriented functions and server executed business logic require frequent requests for data and rules execution and, thus, frequent round trip communications. Likewise, clients and/or servers that are engaged in enterprise level processing activities such as, for example, enterprise optimization activities, are also typically involved in the frequent coordination and communication of large amounts of information or data. Thus, such enterprise level activities similarly aggravate the communication inefficiencies and difficulties of known client-server architectures (e.g., limited bandwidth, high data transmission costs, communication channel latency, etc.)
To reduce the demands placed on communication channels within a process control system, plant and/or enterprise (and the implementation and maintenance costs associated therewith), some systems have maintained known or traditional client-server architectures but have moved substantial amounts of data, business logic, database rules execution and data processing logic from the servers to the clients. In general, all information or data and rules that could potentially be used by the clients are moved to local storage associated with those clients. In this manner, the clients can locally access needed information, data, rules, etc. to perform their activities, thereby reducing or minimizing the amount of network communications required to do so.
Unfortunately, pushing such substantial amounts of data, rules execution, and other processing responsibilities down into client systems results in “heavy” clients that are difficult to install and administer. Further, a system based on the use of such heavy clients within a system configured in accordance with known client-server architectures results in systems that are relatively inflexible and that are not readily scalable. In particular, many systems utilizing existing client-server architectures rely heavily on ad-hoc client logic and data transport formats. In other words, each of the client applications may implement its own versions of rules and database structures. As a result, a simple database change or a change to a rule used by more than one client may require an independent and time consuming reconfiguration of a large number of client applications that could potentially use the database and/or rule. Furthermore, because the clients may be based on different types of systems, which may be associated with different manufacturers, development teams, etc., the specific manner in which a given rule has to be implemented may vary significantly from client to client, thereby making system maintenance (e.g., modification or improvement) activities very complicated and expensive. Furthermore, adding a client or server to such an existing system may require a time consuming configuration of that client to enable that client to execute one or more rules in a desired manner and to enable other clients and/or servers within the system to interoperate with the added client or server. Unfortunately, the ad-hoc code developed for already existing client applications often cannot be adapted for use (i.e., reused) with new client applications. As a result, adding a client application to such a system typically results in the development of additional new ad-hoc software or code.